Add four licenses, see individual commits#102
Conversation
|
I anticipate there to be discussion regarding some choices I made. E.g. the "...WITH LicenseRef-scancode-openssl-exception-lgpl-3.0plus" comes in another variant "LicenseRef-scancode-openssl-exception-lgpl-3.0-plus", but in this instance our scandcode version gives the first variant so it needed to be added. Also is it appropriate to squash the two last commits into one? |
| - "property:include-in-notice-file" | ||
| - "include-in-notice-file" |
There was a problem hiding this comment.
This is probably getting a bit nit-picky, but I'm really interested in your view: Strictly, the license text says "You cannot delete this copyright notice" (emphasis mine). It does not say to include a copy of the notice in the distribution of the app using the dependency.
By just using a Bahyph-licensed dependency, we're not deleting its notice (but we're also not including it explicitly in our distribution). So, isn't it too strict to say the license would demand to "add the relevant copyright notices and the license text into the project/product notice file" (which is the description of the include-in-notice-file category)?
There was a problem hiding this comment.
Perhaps I'm too much on the side of caution here. The license says: You cannot delete this copyright notice. If you change this software, you must include comments explaining who, when and why.
My thinking is that the latter obligation might become completely hidden, if the notice is not distributed. So the authors possibly inteded for the notice to be distributed in documentation. And the notice obligation is very light.
While it is usual that sw would normally not be be changed without access to source code, in this case this is about a dictionary, so the chance is perhaps not totally unexistent. On balance, the notice obligation is so light, and the purpose of marking modifications could disappear without reproducing the notice, so I added it.
Anyhow, I may be wrong on the technical side regarding modifications, and I'm clearly making an interpretation on the sidelines of the text. As it is erring on the side of caution, it is not a problem. But as it is also not clearly existing there, I'm happy to remove the notice obligation too.
There was a problem hiding this comment.
So the authors possibly inteded for the notice to be distributed in documentation.
I agree that's what they probably intended, but they do not say that.
As it is erring on the side of caution, it is not a problem. But as it is also not clearly existing there, I'm happy to remove the notice obligation too.
I'm fine with keeping it. I just was curious about whether we'd agree on our interpretation to be on the side of caution, and not to be strictly clear.
As a general remark, exactly the written-out thinking from your post above should actually go to the commit message for future reference outside of this PR discussion.
No. The proper fix would be to edit the commit that adds "Bahyph", and move it to the correct position in the first place. That said, I believe we should sort licenses case-insensitively (also see oss-review-toolkit/ort#3289). But let's do that as a follow-up PR. |
To me, this clearly should be "LicenseRef-scancode-openssl-exception-lgpl-3.0-plus" to match https://scancode-licensedb.aboutcode.org/openssl-exception-lgpl-3.0-plus.html. Let's discuss in the daily about this. |
So I'll just make a license conclusion for this? |
Not necessarily. I wanted to discuss this in the daily, but you jumped off too early 😬 Anyway, the point is that I first would like to understand where "...3.0plus" (without the dash) comes from, because ScanCode's source code does not seem to contain that string anywhere... I'll try to investigate a bit. |
It comes from here, so the less correct "LicenseRef-scancode-openssl-exception-lgpl3.0plus" is used as the primary |
I've made up my mind about this: Yes, let's do a license conclusion and then only use the proper name in this PR. That's the quickest way forward for us. |
|
Additionally, I did aboutcode-org/scancode-toolkit#4807. |
|
Let me change the commits accordingly, and remove the oddly id'd exception. |
willebra
force-pushed
the
willebra20260311
branch
from
f98df91 to
03c2892
Compare
|
While we don't enforce strict rules on the commit messages in this repo, I'd appreciate if you still could:
|
|
What typos do you see? Did you consider the rationale too lightly explained with respect to Bahyph so it should both be extended and moved to commit body? |
I saw a typo in "mofidication". Maybe there's more.
Yes. Just compare the amount of text you wrote here to your commit message here. There's too big of a discrepancy for me. And the other commits deserve similar sophisticated commit messages. For any reader of the Git commit history (not this PR discussion) it should be totally transparent and comprehensible how you came to the conclusions you made WRT the categorization. |
I have deemed this license to be permissive. It is an early and informally written license that is classified in the ScanCode LicenseDB as permissive. While it lacks the words copy, modify and distribute, it says "made to the public in the hope that they will benefit others" and notes about benefits of spreading the content, amounting to an implied distribution and copying license. Further the requirements on modification include an implied right to modify. I have added the property:include-in-notice-file to the license even if the license just says: 'You cannot delete this copyright notice.' That statement is followed with: 'If you change this software, you must include comments explaining who, when and why.' The latter obligation might become completely hidden, if the notice is not distributed. The authors possibly intended for the notice to be distributed in documentation. And the notice obligation is very light. Since this file is about a dictionary, the chance that it is modified without access to source code, exists. On balance, the notice obligation is light, adding an extra obligation is not a compliance issue and the requirement of marking modifications could disappear without reproducing the notice, so I added it.
willebra
force-pushed
the
willebra20260311
branch
from
03c2892 to
52dd3bd
Compare
|
I made a longer commit message for the Bahyph license. Anyhow, I don't think we should move to a practice where these are all justified in this detail. But here I justified all the choices consistently to show what it would look like. It took me roughly 30 mins, so perhaps a total of 45 mins with classifying the license, if we don't count any of the git adminstration, mostly due to me not being proficient with the tool. |
So we probably need an ORT Server UI for that 😉 |
2 participants
No description provided.